Microsoft Lync Server 2010 : Planning for Deploying External Services - Firewall Configuration (part 1)

When planning a Lync Server environment, any remote access or federation features require significant firewall configuration to ensure the features work correctly and to properly secure the infrastructure. Many different firewall vendors, devices, and configurations can be used to achieve the goal.

The key points to keep in mind are as follows:

• The Edge Server has two network adapters to account for, and two different sets of rules must be created.

• The Edge Server requires at least two network adapters. One is internal facing and communicates with the internal Front-End Servers, Directors, and clients, and the second adapter communicates with the external traffic from the Internet.

Organizations might have a dedicated network security team that is different from the team responsible for implementing and managing Lync Server. Because the deployment planning typically crosses different teams, it is important for all parties to meet early in the planning stages to discuss the deployment requirements. Much of the work and troubleshooting with Edge Server firewall configuration is a collaborative effort between multiple teams to ensure each component is configured correctly.

The following section discusses the different firewall topologies that can be used for Lync Server and key considerations for each design.

1. Back-to-Back Firewalls

The ideal approach to any perimeter network or DMZ is to utilize two different security devices where one provides a layer of defense from the Internet to the perimeter network and the second provides another layer of defense by filtering traffic between the perimeter network and internal network. The Lync Server Edge Servers are situated between the two firewalls in the perimeter network. This approach is illustrated in Figure 1.

Figure 1. Back-to-Back Firewalls

In this configuration, the Edge Server has the external-facing adapter connected to the more external perimeter network and the internal adapter residing in the internal or more trusted perimeter network.

2. Three-Legged Firewall

A three-legged firewall approach can be used when it is not feasible to have two physically separate firewall devices separating traffic from the different network segments. Typically, a smaller organization does not have or want a back-to-back firewall, so a single device is used instead to logically construct the same functionality as a back-to-back firewall provides. This single firewall device is generally at least three physical network interfaces or “legs” that are all connected to different networks: one to the public Internet, one to the perimeter network, and one to the internal network. In this scenario, the Edge Server has all network adapters connected to the same network segment. Figure 2 shows the logical layout of a three-legged firewall design.

Figure 2. Three-Legged Firewall

Firewall rules can still be used to control the flow of traffic between each segment like in a back-to-back scenario, but the primary difference here is that all traffic is run through the same physical device. Whether it is external traffic destined for the perimeter network or perimeter traffic destined for the internal network, it all flows through the same device.

The primary advantage of a three-legged firewall is that it is generally less expensive because only a single device is required. The disadvantage is that although a three-legged firewall can be used to simulate a back-to-back configuration, setting up the rules can be more difficult to configure, manage, and troubleshoot. It can be easy to mistakenly associate a rule with the wrong source or destination interface.

Another downside compared to a back-to-back firewall design is that if an attacker compromises the firewall, access to all network segments is achieved. Instead of having to infiltrate both firewall devices, simply using one exploit grants access to all networks. That said, a three-legged firewall design is popular for small- and medium-sized businesses.

3. No Perimeter Network

If there is no perimeter network, a last-resort option is to leave both Edge Server adapters as part of the internal network. In this configuration, both Edge Server interfaces are part of the internal network, and NAT can be used to expose the required Edge services.

Although this approach can work, from a technical perspective it is not ideal for the following reasons, as shown in Figure 3:

• The only firewall exception for the Edge Server’s interface to reach back to internal network Front-End or Directors should be TCP 5061 for MTLS SIP communication.

• If the internal adapter is instead part of the internal network, there is no filtering or restrictions for other ports.

• If an Edge Server is compromised by an attacker, an attack to any internal server and port can be attempted without restriction. Instead, if the internal interface is properly secured, an attacker is able to use only TCP 5061 to reach a Front-End or Director.

Figure 3. No Perimeter Network

Straddling the Internal Firewall

Another firewall that, unfortunately, is used too often is where the internal interface of the Edge Server does not pass through any firewall. Instead, it straddles the firewall by being connected directly to the internal network. Administrators still secure the external adapter in this scenario. However, instead of creating the appropriate rules for the internal adapter, they just place it on the internal network.

Figure 4. Lync Server Firewall Straddling

There is not much benefit to straddling a firewall with the internal adapter because, just like the previous scenario, several risks are associated with placing the internal adapter directly on the internal network. Furthermore, if the time has been taken to properly secure the external adapter, much of the hard work has already been completed.

Typically, routing has been planned and validated, so creating the few remaining rules should be fairly easy. Spend the extra time to properly secure the internal adapter to protect the rest of the Lync Server infrastructure.